home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 5833 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.1 KB
  1. Path: surfnet.nl!sun4nl!xs4all!usenet
  2. From: jtv@xs4all.nl (Jeroen T. Vermeulen)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: Speed:  68040 vs. 68060
  5. Date: Sun, 25 Feb 96 15:34:52
  6. Organization: Leiden University, Mathematics & Computer Science, The Netherlands
  7. Distribution: world
  8. Message-ID: <19960225.7AF9790.E534@asd10-22.dial.xs4all.nl>
  9. References: <4foi00$60t@gondor.sdsu.edu> <3125E74D.3390@gih.no> <19960223.425E10.10CBD@an100.du.pipex.com>
  10. NNTP-Posting-Host: asd10-22.dial.xs4all.nl
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset=iso-8859-1
  13. Content-Transfer-Encoding: 8bit
  14. X-NewsSoftware: GRn 2.1 Feb 19, 1994
  15.  
  16. In article <19960223.425E10.10CBD@an100.du.pipex.com> m.hendry@dial.pipex.com (Mathew Hendry) writes:
  17. >
  18. > Try the BYTEMark tests on Aminet, which contain compiled algorithms designed
  19. > to simulate real world applications. They are scaled to performance - faster
  20. > CPUs are given bigger tasks. The results are benchmarked relative to a Dell
  21. > P90, which was quite humbling for my poor Amiga and its aging 40MHz '030 :(
  22. > (approx. 10% of a P90 for integer routines, BTW. Even slower for FP)
  23.  
  24. On my own port I got results that said the Pentium is about equal to the 68040
  25. *per cycle*.  This is without touching the timing code; I don't think it takes
  26. multitasking into account so the Amiga may get artificially low results because
  27. of this.
  28.  
  29. As for FP performance, I didn't look through the source all that closely but it
  30. seemed to me that the FP tests happened to hammer mainly on the few FP
  31. instructions that aren't implemented on the 040 (and are trapped by SW
  32. emulation).  Here too the Amiga could be getting results that can be said to be
  33. artificially low by a very large factor.
  34.  
  35. Comparing compilers (SAS vs. gcc) gcc wins for FP (probably because it knows how
  36. to inline code for those emulated instructions) but SAS generally gets some
  37. performance wins out of integer code.
  38.  
  39.  
  40. > : If code is optimised for an '060 is has more chance of running 2 or more
  41. > : instructions at once then unoptimised code.
  42. >
  43. > Only when a compiler appears which produces code optimised for the '060 can
  44. > you run such tests. Contriving code in assembly language to take advantage of
  45. > new CPU features provides misleading results unless a current compiler (as
  46. > used in the REAL WORLD) optimises code in the same way. Since SAS has
  47. > apparently abandoned support for SAS C/C++ I don't see this happening anytime
  48. > soon. So, your only real world estimates at the moment should be based on
  49. > code compiled for the 68040.
  50.  
  51. At the introduction of the 060, Motorola disected a piece of SPECmark code (some
  52. important loop) as generated by existing compilers, and showed how it ran at a
  53. consistent 0.7 cycles per instruction.
  54.  
  55. Of course they wouldn't exactly be showing the worst case here, but OTOH an
  56. optimizer for the new chip could conceivably still improve on that loop (and
  57. certainly in the general case).
  58.  
  59. Anyway, I do think gcc has a scheduler.
  60.  
  61.  
  62. > BTW, as far as I know the current AmigaOS itself doesn't recognise an '060.
  63. > The CPU flags in execbase.h only extend up to the 68040. They also show a
  64. > possible lack of forethought -
  65. >
  66. > /*  Processors and Co-processors: */
  67. > #define AFB_68010   0    /* also set for 68020 */
  68. > #define AFB_68020   1    /* also set for 68030 */
  69. > #define AFB_68030   2    /* also set for 68040 */
  70. > #define AFB_68040   3
  71. > #define AFB_68881   4    /* also set for 68882 */
  72. > #define AFB_68882   5
  73. > #define AFB_FPU40   6    /* Set if 68040 FPU */
  74. >
  75. > Surely they should have left a gap after AFB_68040 to allow for new additions
  76. > to the 680x0 line ;)
  77.  
  78. Don't forget though...
  79.  
  80. /* #define AFB_RESERVED8   8 */
  81. /* #define AFB_RESERVED9   9 */
  82.  
  83. Lack of forethought?  AFB_RESERVED8 must be for the 68060 and AFB_RESERVED9 for
  84. the POWERAmiga.  Note how they predicted the *exact* transition point.
  85.   ;-)
  86.  
  87.  
  88. > -- Mat.
  89.  
  90. --
  91. ============================================================================
  92. #  Jeroen T. Vermeulen   \"How are we doing kid?"/   Yes, we use Amigas.   #
  93. #---  jtv@xs4all.nl    ---\"Oh, same as always."/--         ...          --#
  94. #jvermeul@wi.leidenuniv.nl \ "That bad, huh?"  /  Got a problem with that? #
  95.